# Chapter 13: Authentication

Helix Universal Server authentication provides a way to control what or who can access your Helix Universal Server, whether an encoder sending a broadcast stream, a colleague perusing Helix Administrator, or a user viewing paid content. This chapter explains how to set up user name and password authentication, as well as validation through media player IDs.

| Note: Chapter 12 describes how to limit access to media based on media players' IP addresses. The section "Controlling Connections" explains how to limit connections according to outgoing bandwidth use, total number of players, and other general criteria.

# Understanding Authentication

Authentication verifies the identity of the users or software programs that make requests of Helix Universal Server. It usually takes the form of user name and password validation, though this is not necessary in all cases. The following sections describe the major authentication features and components.

## Types of Authentication

There are several types access requests that you can authenticate, such as viewers requesting media, or Helix Universal Server users logging into Helix Administrator.

### Media Viewer Validation

The most common use of authentication is to validate viewer access to on- demand clips or broadcasts. Helix Universal Server can require a standard user name and password combination that the viewer enters when requesting secure content. Or, you can have viewers register their players' globally unique identifiers (GUIDs). Helix Universal Server then validates access requests automatically, without asking viewers for user names and passwords.

The following table lists supported media players and the types of authentication that you can use with them. `Basic`, `RealSystem 5.0`, and `Windows NT LAN Manager` are forms of user name and password validation, as described in "Authentication Protocols".

Media Players and Supported Authentication Types
Media Player | Basic | RealSystem 5.0 | Windows NT LAN Manager | player GUID
--- | --- | --- | --- | ---
RealPlayer 3 and earlier | no | no | no | no
RealPlayer 4 | no | no | no | yes
RealPlayer 5 and higher | yes | yes | yes | yes
Windows Media Player | no | no | no | no
QuickTime Player | yes | no | no | no
Any other RTP-based player | no | no | no | no

| For More Information: See the section "Setting Up Basic Media Authentication" for the basics of user name and password authentication. "Validating Media Player IDs" explains validation through player GUIDs.

### Administrator Authentication

Accessing Helix Administrator requires a valid user name and password. As explained in "Starting Helix Administrator", the URL used to access Helix Administrator contains the `/admin/` mount point, which automatically authenticates the login. The installation process creates the initial user name and password pair, but you can add additional user names and passwords to the `SecureAdmin` realm, as described in "Managing Users and Passwords".

### Encoder Validation

User name and password authentication for live or simulated live streams sent to Helix Universal Server is generally required for these encoders:

- Helix Producer 9 running in account-based mode. See "Setting Up Account-Based Broadcasting" for information about this broadcast mode.

- RealProducer G2 through 8.5. The section "Encoding with an Older Version of RealProducer"

- SLTA running in basic mode. For more information, see "Basic Mode Configuration".

Although these encoders can use the main user name and password you use to log into Helix Administrator, RealNetworks recommends that you add additional user name and password pairs to the `SecureEncoder` realm for each live broadcast encoder. See "Managing Users and Passwords" for more information.

#### Password Validation Not Part of the Authentication System

Communication between the following components and Helix Universal Server typically require password validation:

- Helix Producer 9 running in push or pull mode.

- SLTA running in advanced mode.

- Transmitters and receivers in splitting arrangements.

- Third-party media encoders.

This validation is not performed by the authentication system, however. Generally, the required passwords are defined on the encoder in its interface or configuration file. On Helix Universal Server, you use Helix Administrator to set up the passwords, which are stored in the configuration file.

### Content Caching Subscriber Authentication

Content caching subscriber authentication is initiated by the content caching file system when making a request to the publisher server from the subscriber server. Like administrator and encoder authentication, the user name and password you enter during setup is also the default user name and password required for content caching subscribers. You can add additional user name and password pairs to the `SecureCDist` realm, as described in "Managing Users and Passwords".

| For More Information: The subscriber server sends the authentication user name and password with its request for content. For more information, see "Setting up Content Caching Subscribers".

## Authentication Components

As you set up authentication, you work with several components. Databases store privileges. Realms validate user names and passwords. Commerce rules determine which on-demand clips and live broadcasts are secure. And permissions grant access to content on a user-by-user basis.

### Databases

On each authentication request, Helix Universal Server verifies the user's password and permissions in a database. Helix Universal Server installs a number of flat file databases, as described in "Using Databases". It uses different databases for different types of authentication. One database holds permissions for media players, for example, while another verifies the identity of encoders that deliver live broadcast streams.

To implement authentication on a limited scale (a few hundred users, for example), use the predefined flat file databases. This requires no additional database configuration. For large-scale implementations of authentication, however, you can tie Helix Universal Server's authentication system to an ODBC-compliant or mSQL relational database. On Windows NT systems, you can also tie authentication into an existing LAN manager database.

| For More Information: For more about databases, see "Using Databases". Appendix C explains the database structure, which you'll need to know to use a relational database for authentication. See also "Windows NT LAN Manager".

### Realms

An authentication realm indicates the database that stores a user's name and password, and specifies the authentication protocol used to validate the user's identity. An authentication protocol, which is not related to streaming protocols such as RTSP, determines how passwords are encrypted in the database. You can use a basic encryption protocol, or a more secure protocol that works with RealNetworks media players only.

| Tip: Helix Universal Server predefines several realms. Depending on your authentication needs, you may not need to change or add realms. For more on realms, see "Setting Up Realms".

### Commerce Rules

Commerce rules determine which on-demand clips or live broadcasts require authentication. Helix Universal Server predefines a set of commerce rules, each rule creating a protected path that leads to secure content. One rule protects all on-demand clips residing in the default security directory, for example. You can set up additional commerce rules as needed. For example, you'll need to create a new commerce rule, or modify an existing one, to secure clips that reside on a network drive.

| Note: Commerce rules work only for media access, and do not apply to other forms of authentication, such as encoder validation. For more information, see "Defining Commerce Rules".

### Permissions

Permissions attach to commerce rules to govern which users can view which clips or broadcasts. Using permissions, you can grant different users access to different secured clips. You can also grant viewing access that expires at a certain date and time, for example, or that is limited to a total amount of time. Although permissions are enforced by default, you can turn them off to give all authenticated users unlimited access to the content protected by a commerce rule. When you turn off permissions for on-demand content, for instance, all authenticated users have unlimited access to all secured, on- demand clips.

| For More Information: For specifics about the permissions that you can grant, see "Handling User Permissions".

## Authentication Used with Other Features

Authentication works with all other Helix Universal Server features. There are few special considerations for each feature, however.

Authentication Used with Other Features
Other Feature | Notes
--- | ---
On-Demand Streaming | All on-demand files stored in the `Secure` directory (or in any subdirectories) are authenticated automatically, once the authentication feature has been set up.
Live Unicasting | Once the authentication feature has been set up, live broadcasts are authenticated automatically if they include `/secure/` as part of the path when you encode the events.
Archiving | Archived files are on-demand files that can be authenticated if they are moved to the correct location. They must be placed in the `Secure` directory or in a subdirectory of `Secure`, or the archiving feature must be configured to use the `Secure` directory.
SLTA | Just like any other live event, broadcasts created by SLTA can be authenticated, as long as you include `/secure/` in the broadcast path.
Splitting | If you are sending a stream to a Helix Universal Server that is acting as a receiver, you must put copies of all the databases that store authentication information on the receiver. This distributes the authentication load.
Multicasting | In back-channel multicasts, the user or client is authenticated through the initial control channel connection. Be sure the multicast (`/`) path is on the list of commerce rules. Authentication does not function with scalable multicasts.
Helix Universal Proxy | Helix Universal Proxy makes requests on behalf of clients, and caches the streams it receives. Although Helix Universal Proxy stores the streamed data, it requires a control channel between the requesting client and Helix Universal Server. Helix Universal Server uses the control channel to request and receive authentication information.
Firewalls | Authentication is performed over the two-way control channel. As long as the client can establish a connection through the firewall to Helix Universal Server, all material can be authenticated for clients behind firewalls.
Access Control | Access control verification, which checks the client's IP address against a list of allowed addresses, occurs before authentication. So if a client's IP address is blocked, authentication will not take place. If users who should be able to view secure material receive error messages, check the list of access rules to see if their client addresses are disallowed.
ISP Hosting | Authentication of content cannot be applied to the files of ISP-hosted customers. Their material is always available. Depending on the access needs, you may be able to apply access control rules so that customers can allow or deny certain users' access to content.
Monitoring | You can monitor which secure presentations are in use by viewing the paths of the files in Server Monitor. Those that contain the `/secure/` mount point are authenticated.
Reporting | Efforts to authenticate users are not included in the access log; records are created for successful serves. You can identify authenticated material in the access log by the `GET` statement. Secure material always contains the `/secure/` mount point in the path. In addition, connection attempts for authenticated material are stored in the `accesslog.txt` file in the `Logs` directory of appropriate data storage directory (if you are using the text file method), or in the `Access_log` table (if you are using the database method).

# Setting Up Basic Media Authentication

The following sections explain the basics of how to secure on-demand clips and broadcasts through user name and password validation. They explain where to place clips, how to secure a broadcast originating from an encoder, and how to write URLs to the secure content. When you use the Helix Universal Server default settings, there are two setup steps you need to perform through Helix Administrator to implement user name and password checking:

1. Add user name and password combinations according to the instructions in "Managing Users and Passwords".

2. Define user permissions (or turn them off), as described in "Handling User Permissions".

In some cases, you may need to change certain default settings for databases and realms, depending on your authentication needs:

- If you are not using one of the predefined flat-file databases for storing passwords, you need to set up your database first, as described in "Using Databases".

- When you create a new database, you must associate a new or existing realm with it, as described in "Setting Up Realms".

- To validate access attempts from QuickTime Player, set the `Basic` authentication protocol in your authentication realms. For instructions on doing this, see "Creating or Modifying a Realm".

- If you want to validate media player requests based on each player's ID, rather than on the users' names and passwords, refer to the instructions in "Validating Media Player IDs".

## Securing On-Demand Content

To require user name and password validation, you place clips in Helix Universal Server's `Secure` directory instead of in its `Content` directory. In a default installation on Windows, the `Secure` directory is here:

    C:\Program Files\Real\Helix Server\Secure

Installation paths vary on UNIX, but the `Secure` directory is under the main installation directory, as in this example:

    /usr/local/Real/HelixServer/Secure

Helix Universal Server identifies requests for secure, on-demand clips through a `/secure/` mount point that precedes the clip name in the request URL. This mount point is created during installation, and automatically requires authentication for all content in the `Secure` directory. The following is an example of a Web page URL to a secure clip:

    http://helixserver.example.com/ramgen/secure/video1.rm

| For More Information: See "Writing Links to Content" for background on link formats, mount points, and URLs used in Ram files.

### Adding Subdirectories to Implement Permissions

You may want to create subdirectories within the `Secure` directory, then set up permissions as described in "Handling User Permissions" to define exactly which viewers can access which clips in which subdirectories. In this case, the request URL includes the subdirectory path, which can be any number of levels deep, after the `/secure/` mount point:

    http://helixserver.example.com/ramgen/secure/dailyvideo/video1.rm

### Placing Secure Clips in Other Directories

You can store secure, on-demand clips in directories other than the default `Secure` directory. This allows you to store secured clips on other drives or network machines. To do this, you define a new, secure mount point used in place of the default `/secure/` mount point.

| To create a new security mount point for on-demand clips:

1. Create a directory on your Helix Universal Server machine or your network to store your secure clips. This directory must not be a subdirectory of the existing `Content` or `Secure` directory.

2. Add a new mount point, such as `/secure2/`, that points to the new directory. For instructions on doing this, see "Adding a Mount Point for On-Demand Clips".

3. Follow the instructions in "Adding or Modifying Commerce Rules" to create a commerce rule that provides access to this new protected path.

4. Set up permissions for individual users to view content in the new protected path, as described in "Handling User Permissions".

As shown in the following example, a URL to a clip in the new secure directory uses the mount point you define:

    http://helixserver.example.com/ramgen/secure2/video1.rm

When Helix Universal Server receives a request to this protected path, it initiates authentication to verify that the user or player exists in the proper database according to the commerce rule that protects the `/secure2/` path.

## Securing Broadcasts

To secure a live or simulated live broadcast, you include the `/secure/` mount point after the broadcast mount point in the request URL:

    http://helixserver.example.com/ramgen/broadcast/secure/live.rm

Live or simulated live broadcasts do not correspond to actual files on Helix Universal Server. When a broadcast mount point such as `/broadcast/`, `/encoder/`, or `/live/` precedes the `/secure/` mount point, Helix Universal Server performs authentication, but does not search for a file in its `Secure` directory. Instead, it delivers the live stream associated with the broadcast mount point.

### Specifying the Secure Path on the Encoder

The encoder that delivers the live or simulated live stream must include the `/secure/` virtual path along with the broadcast file name to indicate that this stream requires authentication. In Helix Producer, for example, you specify the live stream as `secure/live.rm` instead of just `live.rm`.

| For More Information: Predefined commerce rules govern access to broadcasts from different encoders. For more information, see "Default Commerce Rules".

# Managing Users and Passwords

The following sections explain how to manage the user names and passwords of authorized users for any type of authentication, whether individuals requesting secured clips, encoders connecting with live streams, or additional users of Helix Administrator.

| Note: If you are using Windows NT/2000/XP to manage the list of users, passwords, and groups, use those tools instead of the instructions below. To use Windows passwords, you need to set the NTLM authentication protocol in your selected realm, as described in "Creating or Modifying a Realm".

## Adding a User

Follow the procedure below to add a user and password to an authentication realm. To use a database other than one that is predefined, you must create that database and associate it with the proper realm before adding users. Refer to "Using Databases" and "Setting Up Realms" for more information.

| Note: The Helix Administrator interface does not provide a way to add multiple user names and passwords at one time.

| To add a user name and password:

1. Click Security>Authentication.

2. In the Authentication Realms list, select the realm to which you want to add a user. The following realms are predefined:

   `SecureAdmin` | Helix Administrator users
   `SecureCDist` | content caching subscribers
   `SecureContent` | media player users
   `SecureEncoder` | RealProducer G2 through 8.5 delivering live broadcast streams
   `SecureRBSEncoder` | Helix Producer delivering live broadcast streams, and SLTA delivering simulated live streams in basic mode

| For More Information: Realms are described in "Setting Up Realms".

3. Click Add a User to Realm.

4. In the pop-up window, define the user's name in the Name box. User names are case-sensitive. You can use separate words if, for example, you want to use full names of users.

5. In the Password box, supply the user's password. Passwords are case-sensitive. RealNetworks recommends following good password practices:

- Avoid common words that are easy to guess.

- Do not use a word associated with the user, such as a first name.

- Do not use the same password for multiple users.

- For highest security, use a random combination of letters and numbers in different cases.

| Tip: Keep track of the passwords you assign. Helix Administrator allows you to change passwords, but not to look them up.

6. In the Confirm Password box, type the password again.

7. Click OK.

## Deleting a User

The following procedure explains how to delete a user from a database. Helix Administrator does not have a bulk delete feature.

| To remove a user:

1. Click Security>Authentication.

2. In the Authentication Realms list, select the name of the realm in which you want to delete a user. The predefined realms are described in "Setting Up Realms".

3. Click Remove a User from Realm.

4. In the new window that appears, enter the user's name in the Name box.

5. Click OK.

## Browsing All User Names

The browsing feature lists all user names defined for an authentication realm.

| To browse all users:

1. Click Security>Authentication.

2. In the Authentication Realms list, select the realm you want to browse. The default realms are described in "Setting Up Realms".

3. Click Browse Users in Realm. The pop-up window lists all user names defined for that realm.

## Changing a Password

The following procedure explains how to change the password for an existing user. The Helix Administrator interface does not allow you to look up existing passwords.

| To change a password:

1. Click Security>Authentication.

2. In the Authentication Realms list, select the name of the realm that contains the user. The predefined realms are described in "Setting Up Realms".

3. Click Change User Password.

4. In the new window that appears, enter the user's name in the Name box.

5. In the Password box, specify the user's new password.

6. In the Confirm Password box, type the password again.

7. Click OK.

## Using the Password Tool

When it uses the RealSystem 5.0 authentication protocol, Helix Universal Server encrypts passwords, so you cannot look up the passwords directly. However, you can add or change passwords in a flat file or relational database by using a command-line utility. You can even create a password interface by integrating this utility with your own CGI scripts and Web pages.

| For More Information: See "Authentication Protocols".

| To use the password tool:

1. Open a command prompt and navigate to the `Bin` directory under Helix Universal Server's main installation directory.

2. Enter the following command:

    mkpnpass username realm

using the following values:

`username` | The user name exactly as it is entered, or will be entered, in the authentication database.

`realm`

The value of the Realm variable specified in the relevant list.
For Helix Producer, this is given in the Authentication field under Broadcasting>RealNetworks Encoding. In the configuration file, it is given by the value of the `Realm` variable in the `G2_Encoders` list.
For Helix Administrator users, use the value of the `Realm` variable in the `RealAdministrator_Files` list within the `FSMount` list in the configuration file.

3. A password prompt appears, followed by a prompt to type the password again. The resulting encrypted password is displayed on the screen.

Helix Universal Server encrypts passwords with the MD5 hashing algorithm. It uses the form `MD5("``username:realm:new_password``")`. On BSD systems and some other UNIX systems, you can generate these passwords with the following command:

    echo -n "username:realm:new_password" | md5

4. Add the resulting encrypted password into the appropriate field of the database:

- For text files, place it in the password field of the `Users` directory. See "Users Directory".

- For databases, place it in the password field of the `Users` table. See "Users Table".

# Using Databases

In its default configuration, Helix Universal Server uses a set of flat files to store user names, passwords, and permissions. For large-scale implementations of authentication, RealNetworks recommends that you tie Helix Universal Server into an ODBC-compliant or mSQL database that stores this information. The following table lists the flat file databases automatically installed with Helix Universal Server.

Default Databases
Name | User Names and Passwords | Purpose
--- | --- | ---
`Admin_Basic` | Helix Administrator. | Validate access to Helix Administrator.
`CDist_Basic` | registered content caching subscribers | Verify subscribers requesting content from a publisher.
`Content_RN5` | content users | Validate users requesting secured on-demand or live content.
`Encoder_Basic` | Helix Producer | Verify content creators delivering live or simulated live broadcasts.
`Encoder_RN5` | RealProducer G2 through 8.5 | Verify content creators delivering live or simulated live broadcasts.
`PlayerContent` | player GUIDs and user names for viewers accessing content | Validate unique IDs for players accessing content.

## Supported Database Types

Helix Universal Server provides interfaces to several types of databases. Appendix C contains details about the database structure, which you'll need to know to integrate Helix Universal Server's authentication system with a relational database, for example.

### Flat File Database

The default databases used for authentication are flat text files, which work well for storing relatively small amounts of data, such as a few hundred user names and passwords. You may want to use them to learn the authentication data structure before linking Helix Universal Server to a more robust relational database. If you choose to use the default flat files exclusively, you do not need to perform any additional configuration.

### ODBC and mSQL

Helix Universal Server includes templates for common relational databases, covering mSQL and ODBC-compliant databases. To use an ODBC or mSQL database, you must configure your database to comply with the appropriate table structure described in Appendix C.

### RN5 DB Wrapper

If you used authentication features with RealSystem Server version 5, or if you have a data store plug-in created by a third-party company, you can use that plug-in with Helix Universal Server version 9.0.

## Adding a Database

Follow the procedure below to add a new database that stores user names and passwords. If you are using the default flat file databases, it is typically not necessary to add a new database.

| To add a database:

1. Click Security>Databases.

2. Click the "+" icon, and type a description for the new database in the Edit Database Name box.

3. From the Database Type list, select the data storage method you want to use. Database types are described in "Supported Database Types".

4. Depending on the database type method you chose, additional information is required.

1. Flat File needs only the path to the main text file directory. For example, the `enc_r_db` directory under the main Helix Universal Server directory. For more information, see "Understanding Authentication Data".

2. mSQL has two required names, and three optional items:

Host Name—IP address or DNS name of computer where the database is stored.

Database Name—Name of the database.

Table Name Prefix—Prefix used to make field names unique, when used with an existing database.

User Name—Name required by the database application.

Password—Password required by the database application. Re-enter your password in the Confirm Password box to ensure that you typed it correctly.

3. ODBC uses the same information as mSQL, but ODBC does not ask for a host name. Refer to "Setting Up Other Types of Data Storage" for further instructions.

4. For RN5 DB Wrapper, the following items are needed:

Database Name—Name or location of the data storage plug-in. Consult your plug-in documentation for information about what should go here.

Plugin Path—Location of the plug-in.

User Name—Name required by the database application.

Password—Password required by the database application. Re-enter your password in the Confirm DB Login Password box to ensure that you typed it correctly.

5. Click Apply.

# Setting Up Realms

A realm connects users to databases. When you define passwords, you add them to a realm. The realm, in turn, specifies the encryption protocol, and indicates the database where information is stored. If you are using the default authentication databases, as described in "Using Databases", you can use the default realms, too, changing the authentication protocols if necessary. If you set up new databases, you need to create new realms, or point the existing realms to your new databases.

Predefined Authentication Realms
Realm | Authenticates | Realm ID | Protocol | Database
--- | --- | --- | --- | ---
`SecureAdmin` | Helix Administrator | `servername``. AdminRealm` | `Basic` | `Admin_Basic`
`SecureCDist` | content caching subscribers | `servername``. CDistRealm` | `Basic` | `CDist_Basic`
`SecureContent` | content users | `servername``. ContentRealm` | `RealSystem 5.0` | `Content_RN5`
`SecureEncoder` | live streams from RealProducer G2 through 8.5 | `servername``. EncoderRealm` | `RealSystem 5.0` | `Encoder_RN5`
`SecureRBSEncoder` | live streams from Helix Producer | `servername``. RBSEncoder Realm` | `Basic` | `Encoder_Basic`

## Authentication Protocols

Authentication protocols determine the password encryption and storage method used by Helix Universal Server. The server supports three protocols. Each realm uses just one protocol.

### Basic

The Basic protocol sends the user's name password over the public Internet in a simple manner, encoding them with the Base64 algorithm. Helix Universal Server decodes and verifies the password. Information can be stored in a flat file or a relational database. This protocol works with RealNetworks media players, as well as the QuickTime Player.

### RealSystem 5.0

Also called RN5, this is a RealNetworks encryption protocol that works with RealPlayer 5 and later. It is more sophisticated and secure than the Basic protocol. Use it if your material will be served exclusively to users who have RealPlayer 5 or later. Information can be stored in a flat file or a relational database.

| Tip: For authentication of QuickTime Player or RealNetworks players earlier than version 5, use the Basic protocol.

### Windows NT LAN Manager

The NTLM method is suitable for a Windows-based intranet. It enables Helix Universal Server to use the existing Windows NT database of user groups. It also allows access control of content through NTFS file permissions. This method requires that Helix Universal Server itself be installed on the Windows NT machine. When using NTLM authentication, be aware of the following:

- NTLM authentication works only with RealPlayer 5 and later.

- All users' accounts must exist on the local NT computer. NTLM authentication will not work with accounts on other servers within the domain, but it will authenticate against accounts on the primary domain controller.

- You add all user accounts through the Windows NT User Manager. Do not use the instructions in "Managing Users and Passwords".

- The built-in guest account is not available for use in authentication.

- When you select NTLM authentication for Helix Administrator access, all groups are authenticated if you do not specify a user group.

- You cannot evaluate permissions on commerce rules when you use NTLM authentication.

- Blank passwords are not supported.

## Creating or Modifying a Realm

The following procedure explains how to create a new realm or modify an existing one. It is generally not necessary to do this unless you have created a new database. Use a one-to-one correspondence between realms and databases. Do not create two realms, for instance, that use the same database.

| To create or modify a realm:

1. Click Security>Authentication.

2. To create a realm, click the "+" icon and enter a name for this realm in the Edit Realm Description box. To modify an existing realm, select it in the Authentication Realms box.

3. In the Realm ID box, type a name that will be used in other areas of Helix Administrator. The realm name may also appear to users as part of the name and password prompt. The default realms conform to the following format:

    servername.Realm_Id

| Warning! You do not have to use the default convention, but you must include a period (.) in the realm ID or the realm will not work properly.

4. In the Authentication Protocol list, select the authentication method you want to use for this realm, as described in "Authentication Protocols".

1. If you choose `Basic` or `RealSystem 5.0`, select the database in the Database box.

2. If you choose`` `Windows NT LAN Manager`, Helix Universal Server uses the NT list of names instead of a database. Type the appropriate provider in the Provider list, such as `NTLM`. Type the Group name in the Group box.

5. Click Apply.

# Defining Commerce Rules

Commerce rules enforce authentication by defining protected paths. For example, the default commerce rule for on-demand clips defines the protected path `/secure/`, which corresponds to the `Secure` directory. When that path appears in a URL request, Helix Universal Server authenticates the request, allowing anyone with a valid user name and password to view clips in that directory. You can modify the default commerce rules, and create new commerce rules, to carry out tasks such as the following:

- Secure clips in locations other than the `Secure` directory. You can create a new commerce rule to secure the `Archive` directory, for example. As the section "Placing Secure Clips in Other Directories" explains, you can also store clips on different network drives or machines, creating a new commerce rule to secure those assets.

- Secure all live broadcasts. Helix Universal Server automatically secures broadcasts that use protected paths such as `/broadcast/secure/` or `/encoder/secure/`. However, broadcasts that use just the broadcast mount points, such as `/broadcast/` or `/encoder/`, are not secured by default.

| Tip: If you changed the protected paths to `/broadcast/` and `/encoder/`, you would secure all broadcasts automatically.

- Allow multiple viewers to use the same user name and password to access an on-demand clip or broadcast. This lets you grant quick access to secured content to everyone within a division or a company, for example.

- Validate player IDs instead of user name and password combinations. For more on this, see "Validating Media Player IDs".

| Note: Commerce rules apply only to viewers attempting to access secure clips or broadcasts. They do not apply to encoders or Helix Administrator users, for example.

## Default Commerce Rules

Helix Universal Server defines a number of commerce rules that provide general access to secured content. For example, these rules allow access to on- demand clips in the `/secure/` path, or to broadcasts in the `/broadcast/secure/` path.

### SecureG2LiveContent

The commerce rule `SecureG2LiveContent` grants access to live broadcasts encoded with RealProducer G2 through 8.5. The rule evaluates the protected path `/encoder/secure/`. Users requesting live broadcasts through this path are associated with the `SecureContent` realm by default, and must have a user name and password defined in this realm to gain access to the secured broadcast.

### SecureLiveContent

`SecureLiveContent` grants access to live broadcasts encoded with Helix Producer 9 and higher, as well as simulated live broadcasts delivered through SLTA. The rule evaluates the `/broadcast/secure/` protected path. Users requesting live broadcast URLs that contain this path are associated with the `SecureContent` realm by default, and must have a user name and password defined in this realm to gain access to the secured broadcast.

### SecurePlayerContent

This commerce rule, which is used for validating media player IDs, grants access to the `player` directory, a subdirectory of the`/secure/` mount point. User and client information must exist in the player database before viewers can access the content. The section "Validating Media Player IDs" explains player ID validation.

### SecurePreG2LiveContent

You use the `SecurePreG2LiveContent` commerce rule for content encoded with versions of RealProducer earlier than RealProducer G2. The rule evaluates the protected path `/live/secure/`. Users requesting URLs containing this path are associated with the `SecureContent` realm and must have a user name and password defined in this realm to gain access to the secured content.

### SecureUserContent

This commerce rule grants access to on-demand content in which the request URL contains the `/secure/` mount point. Users requesting this content are associated with the `SecureContent` realm by default, and must have a user name and password defined in this realm to gain access to the secured content.

## Adding or Modifying Commerce Rules

The following procedure explains how to add a commerce rule, or modify the overall attributes of existing commerce rules. The section "Handling User Permissions" explains how to define permissions for a commerce rule.

| To create or modify a commerce rule:

1. Click Security>Commerce.

2. To create a new rule, click the "+" icon and edit the name that appears in the Edit Rule Name box. To modify a rule, select its name in the Commerce Rules box.

3. In Protected Path, enter the path that appears in the URL to invoke the commerce rule. For example, if you set up a `/secure2/` mount point for secured content, enter `/secure2` (no closing slash) in the box.

| For More Information: For more on creating additional secure mount points, see "Placing Secure Clips in Other Directories".

4. In User Permissions Database, select the database that will store the user permissions. The default database for on-demand content is `Content_RN5`. The table "Default Databases" lists the other default databases.

| Note: You can turn off individual user permissions for the commerce rule by selecting `Do Not Evaluate User Permissions`. In this case, all authenticated users have unlimited access to content protected by the commerce rule.

5. In the Credential Type list, select `Use User Authentication` to require user name and password validation. The other choice, `Use Player Validation`, validates access attempts according to player IDs, which is described in the section "Validating Media Player IDs".

6. If you chose user name and password validation, you next select the realm in the Realm pull-down list. The default realm for on-demand content is `SecureContent`. The table "Predefined Authentication Realms" lists the other default realms. User names and passwords must be defined in the selected realm, as described in "Managing Users and Passwords".

| Warning! You must select the realm associated with the database you chose in the User Permissions Database field.

7. If you selected user name and password validation, you can set Allow Duplicate User IDs to `Yes`. This allows multiple people to use a single user account simultaneously. If you want to distribute a video to all employees in a division, for example, you can allow duplicate IDs and supply all persons in that division with the same user name and password.

8. Click Apply.

| Note: The Player GUID Databases section is used only with player ID validation. The section "Modifying the GUID Database" explains how to use that part of the commerce rules page.

# Handling User Permissions

Permissions are associated with commerce rules. They determine which authenticated viewers can see which content in a protected path. By setting up permissions, you can grant access to clips on a person-by-person and file-by- file basis, for instance. You can also create permissions that allow secured access to clips or broadcasts only at certain times, or for certain durations. Note the following about permissions:

- Permission checking is enabled by default. This means that you must define permissions for individual users to give them access to secured content. Even if users have valid user names and passwords, they will not be able to view any content if they have no permissions defined.

- You can turn off permission checking for a commerce rule by choosing `Do Not Evaluate User Permissions` in the User Permissions Database pull-down list. In this case, all users with valid user names and passwords have unlimited access to all content protected by the commerce rule. For instructions on doing this, see "Adding or Modifying Commerce Rules".

- Helix Universal Server does not evaluate permissions on commerce rules when you use the `Windows NT LAN Manager` authentication protocol. If you are using that protocol, there is no need to define permissions.

## Permission Types

When you associate permissions with a user, you can set up two types of access. You can allow access to entire directories. You can also set up permissions file-by-file, or use a combination of these two methods.

### Directory-Level Access

Directory-level access specifies that a user can view all of the content in a certain directory, as well as in its subdirectories, which inherit the permission. For example, you might give viewer A directory-level access to this path:

    /secure/confidential/

The viewer then has access to files in that path, as well as in any subdirectory below that path. Thus, viewer A can access a clip in this path:

    /secure/confidential/secret/

But viewer A does not have access to a path such as this:

    /secure/topsecret/

### File-Level Access

File-level access grants a user access to a specific file or live broadcast stream. As described below, you can also specify the duration or manner of this access. A single user may have both directory and file access for a clip in the same directory. If the directory access has expired, but the file access is still valid, the viewer can request the valid file, but no others in the directory. Conversely, if the file access has expired but the directory access is still valid, the viewer can request all files in the directory except the expired file.

### Permission Access Types

Whether you give a viewer directory-level or file-level access, you can assign an access type as described in the following table.

Permission Types
Access Type | Permission Granted
--- | ---
Event | Unlimited viewing of a given clip or a directory of clips. This is the default.
Calendar | Permission expires on a certain date and time. If the expiration date and time arrive while the viewer plays a clip or broadcast, transmission stops and an error message appears.
Duration | Viewer gets a finite amount of time to view presentations. All viewing time is deducted from this amount. When the duration time elapses, permission is revoked.
Credit | Time spent viewing presentations is noted in the Helix Universal Server access log, and the administrator can use this information later for billing purposes. Access is granted per presentation or directory, and is unlimited. For information on the authentication access logs, see "Logs Directory".

| Note: With Duration or Credit permissions, Helix Universal Server accurately reports the total time a user views a secure file. If the end time minus the start time does not equal the total viewing time, for example, the discrepancy can be attributed to the user buffering, pausing, or seeking within the file. However, the total viewing time is the value debited or credited against the user's account, depending on the permissions used.

### Permissions for SMIL Presentations

With a SMIL presentation, users are authenticated once regardless of how many files in the presentation are protected. If access to any clip in the presentation expires during the presentation, the presentation halts until more viewing time is allotted. For this reason, it is a good idea to keep permissions on all clips within a SMIL presentation the same. The following are the best methods of implementing authentication for SMIL files:

- Authenticate the SMIL file but not its contents. This is useful if you do not need a high level of security on all clips. In this case, it's a good idea to keep the view source feature set to its default, so that it does not show the full paths to the unsecured clips.

| For More Information: See "Displaying Source Information".

- If you are using duration access, use it only for the longest clip in the presentation, which is typically an audio or video clip. Apply event access for the other files.

#### SMIL Files and Directory-Level Duration Access

If you define directory-level duration access for a SMIL presentation, giving identical permission to all files (including the SMIL file) will not work as you may expect. As each clip plays, Helix Universal Server subtracts the viewing time from the directory allotment. If each clip is 10 minutes long, and there are three clips in the presentation, Helix Universal Server subtracts 30 minutes from the total viewing time. This means that in setting up this type of access, the time allotted must be the sum of all the clips.

| Tip: Keeping track of all the clips, their lengths, and the total directory access time can be tricky. An easier solution is to limit the access time only for the SMIL file.

## Granting Permissions

You can create user permissions for commerce rules by following the procedure listed below. Note the following about defining permissions:

- You can define more than one permission for each user. You can give a single user permission to view several different clips, for example. You must define each permission separately, though, using the same user name each time.

- Each permission is associated with a single commerce rule. Typically, different commerce rules govern access to different directories or broadcasts. If you want to give a user permission to view one on-demand content directory and one broadcast, for example, you define one permission on the commerce rule governing on-demand clip access, and another permission on the commerce rule governing live broadcasts.

- The user name must first be defined in the database used by the commerce rule. For instructions about adding and browsing user names, see "Managing Users and Passwords".

| To grant permissions to a user:

1. Click Security>Commerce.

2. Select the appropriate commerce rule in the Commerce Rules box.

3. Click the Grant User Permission link.

4. In the pop-up window, enter the user's name in the User Name box.

5. For Path Type, select `Directory` or `File` depending on the type of permission you want to add. For more information, see "Permission Types".

6. The Path box indicates the directory or file that the viewer can access. It initially lists the protected path associated with the selected commerce rule. For example, if you're adding permissions to the default commerce rule for on-demand content (`SecureUserContent`), the path looks like this:

    secure/

1. If you've chosen directory-level access, add to the protected path the subdirectory the viewer can access, as in the following:

    secure/confidential

| Note: The viewer can view clips in all subdirectories of the selected path.

2. If you've selected file-level access, enter the subdirectory, if necessary, and the clip file name, as shown here:

    secure/confidential/report.rm

7. The Access Type pull-down list corresponds to permission types described in "Permission Access Types".

1. Set the menu to `Event` to allow unlimited access to the content.

2. If you choose `Calendar`, set an expiration date in this format:

    mm/dd/yyyy:hh:mm:ss

3. For `Duration`, set in seconds the total amount of viewing time allowed.

4. Choose `Credit` to log the viewer's total access time in the access logs.

8. Click OK.

## Editing User Permissions

After you assign permissions to a user, you can edit those permissions to change the viewing expiration date, for example, or give the viewer more or less total viewing time on a directory or file.

| To modify user permissions:

1. Click Security>Commerce.

2. Select the appropriate commerce rule in the Commerce Rules box.

3. Click the Edit User Permission link.

4. In the pop-up window, enter the user's name in the User Name box. See "Browsing All User Names" for information about listing user names.

5. For Path Type, you can select `Directory` or `File` to change the type of permission. For more information, see "Permission Types".

6. The Path box indicates the directory or file that the viewer can access. For more information on this, see Step 6 in the procedure for granting permissions.

7. If you had set an expiration date on the user permissions, you can enter a new date in the New Expiration Date box in this format:

     mm/dd/yyyy:hh:mm:ss

After doing so, click Set New Date.

8. If you set a duration on the user permissions, you can modify the viewing time allowed. Choose `Add` or `Subtract`, and enter the amount of time in seconds. Then click Change Time.

9. Click Close Window.

## Revoking User Permissions

You can revoke some or all permissions granted to a user. Keep in mind, though, that each revocation applies only to the selected commerce rule. If a user has permissions defined for other commerce rules, you must revoke those permissions separately. Helix Administrator does not provide a means for revoking permissions for several users or several commerce rules at a time.

| Tip: See "Browsing All User Names" for information about listing user names.

| To revoke a single permission for a user:

1. Click Security>Commerce.

2. Select the appropriate commerce rule in the Commerce Rules box.

3. Click the Revoke User Permission link.

4. In the pop-up window, enter the user's name in the User Name box.

5. For Path Type, select `Directory` or `File` according to the type of permission you want to revoke. For more information, see "Permission Types".

6. The Path box indicates the directory or file that the viewer can access. For more information on this, see Step 6 in the procedure for granting permissions.

7. Click OK.

| To revoke all permissions for a user:

1. Click Security>Commerce.

2. Select the appropriate commerce rule in the Commerce Rules box.

3. Click the Revoke All Permissions link.

4. In the pop-up window, enter the user's name in the User Name box.

5. Click OK.

# Validating Media Player IDs

For authentication of on-demand content or broadcasts, you can validate media player IDs rather than user name and password combinations. For the privacy reasons described below, this method of authentication is better suited for an intranet, although you can use it with the public Internet. With player ID authentication, users first register their player IDs through a special URL. They can then view protected content without having to enter a user name and password. Media player ID validation works only with RealPlayer 4 and higher.

## Player IDs and User Privacy

For player ID validation to work, players must be configured to send a globally unique ID (GUID) to Helix Universal Server. For privacy protection, the standard RealOne Player that viewers download over the Internet is set by default not to send a GUID, in accordance with RealNetworks' Consumer Software Privacy Statement, which is published on the following Web page:

http://www.realnetworks.com/company/privacy/software.html

Because sending a GUID is solely at the discretion of each user, you must request users to change their default GUID setting (on RealOne Player, the command is Tools>Preferences>Connection>Internet Settings) to register their GUIDs and enable player ID authentication for material delivered over the Internet. Users who decline to do so will be denied access to secure content. However, you can reroute these users to a non-secure Web URL that explains their options, as described in "Setting Up Commerce Rules".

### Using Player ID Validation on an Intranet

In an enterprise setting, you can control whether or not RealOne Player transmits its GUID when you use RealNetworks' Desktop Resource Manager. You can turn GUID registration on by default for all users, making it easier to set up player ID validation on an intranet. For more on Desktop Resource Manager, visit the following Web page:

http://www.realnetworks.com/products/ria/rdm/index.html

## Choosing a Database and Realm for User Names

Helix Universal Server installs a default database, `PlayerContent`, for use with player ID validation. You can use this database, or add your own relational database. You need to associate a realm with the player ID database only to populate it with user names initially. After that, Helix Universal Server refers directly to the database to validate player IDs, and does not refer to the realm again. Note the following:

- If you do not want to use the default `PlayerContent` database (you want to use a relational database instead, for instance), set up your database first, as described in "Using Databases".

- If you do not plan to implement user name and password validation for any on-demand content, you can associate the default `SecureContent` realm with the player ID database you use.

- If you think that you may enable user name and password validation in addition to player ID validation, create a new realm for player ID validation, and associate it with your player ID database. This leaves the `SecureContent` realm available for user name and password validation.

The section "Creating or Modifying a Realm" explains how to create a new realm or modify the `SecureContent` realm. For the realm you decide to use, select the `PlayerContent` database (or the relational database you're using) in the Database pull-down list. You can set the Authentication Protocol to `Basic` or `RealSystem 5.0`. Passwords are not used, so either protocol setting has the same effect.

## Adding User Names to the Player ID Database

After you select your realm for player ID validation, add user names to that realm for each user as described in "Adding a User". Users will then register with Helix Universal Server once using their user names. Helix Universal Server associates each user name with the unique player ID in its database. It validates subsequent access attempts through the ID without asking the user to enter a user name. Because user names are associated with player IDs, though, you can use the names to set up permissions.

| Note: The database structure requires that you enter a password for each user, even though passwords aren't used with player ID validation. You can therefore enter the same password for each user.

## Setting Up Commerce Rules

Helix Universal Server provides a default commerce rule called `SecurePlayerContent` that authenticates access attempts through player IDs. You do not have to change any settings to use this default rule to secure on- demand content. To modify this rule or create a new one, refer to the instructions in "Adding or Modifying Commerce Rules". Note the following about commerce rules used with player ID validation:

- By default, the Protected Path is `/secure/player` rather than `/secure`, which is used with user name and password validation. The `/secure/player` path corresponds to a `player` subdirectory of the `Secure` directory. This subdirectory is not created during installation, however, so you need to create it to use player validation.

| Tip: You can use another directory on your network. To do this, follow the instructions in "Placing Secure Clips in Other Directories", modifying your commerce rule appropriately.

- By default, User Permissions Database is set to `PlayerContent`. Change the database choice if you are using a different database. If you do not want to evaluate permissions, and wish simply to grant all authenticated users access to all content in the protected path, select `Do Not Evaluate User Permissions`.

| Note: If you plan to use permissions for individual viewers, follow the instructions in "Granting Permissions".

- For Credential Type, you must always select `Use Player Validation` for player ID authentication to work.

- Click Redirect Unauthenticated Players to enter a fully qualified HTTP or RTSP redirection URL for viewers who have not registered, or who have chosen not to transmit their player GUIDs.

- To validate live broadcasts through player IDs, create a new commerce rule as described in "Adding or Modifying Commerce Rules", and set Protected Path to `/broadcast/secure/player` (for broadcasts from Helix Producer 9 and later) or `/encoder/secure/player` (for broadcasts from RealProducer G2 through 8.5). On the encoder, specify the virtual path `secure/player/` along with the stream name when starting the broadcast.

## Modifying the GUID Database

The Helix Administrator Commerce page allows you to select the database that registers player IDs. You do not need to change the default setting if you are using the default `PlayerContent` database. You need to change the GUID database settings only if you are not using the default database, or you want to change the prefix used in URLs to register users.

| To modify the GUID database:

1. Click Security>Commerce.

2. Select an existing database name, or click the "+" icon to create a new database entry, naming the database in the Edit Description field. The name is for your reference only.

3. Enter a prefix in the Player Registration Prefix field. You'll use this prefix in URLs that viewers click to register their player IDs, as described in "Creating Registration URLs".

4. Select the database to use through the Player Database pull-down list.

5. Click Apply.

## Creating Registration URLs

To register individual RealOne Players, you create a link that viewers click once to add their players' GUIDs to the database. The registration URL, which users can enter in the File>Open Location box of RealOne Player, looks like this:

    rtsp://helixserver.example.com/registerName!clip.rm

If you add the URL to a Web page link, you use an HTTP URL and `/ramgen/`, as shown here:

    http://helixserver.example.com/ramgen/registerName!clip.rm

Note the following:

- The registration prefix is `register` by default, but can be changed as described in "Modifying the GUID Database".

- After the Helix Universal Server address, you combine the registration prefix with the viewer's user name. For example, you might use `registerMiguel21`.

- For `clip.rm`, specify a clip in the unsecured `Content` directory, not a clip in a secured directory. This can be any clip that the player can display. It may simply be a graphic that indicates a successful registration.

- Once a GUID is registered, subsequent registration attempts are ignored.

## Writing Content URLs

After viewers contact Helix Universal Server through the registration URL, they can begin to access content for which they have permission. Media clips go in the secure directory defined by the commerce rule, as described in "Setting Up Commerce Rules". The default path is the `player` subdirectory (which must be created manually) of the `Secure` directory. Web page links to this content look like this:

    http://helixserver.example.com/ramgen/secure/player/business/video1.rm

In the preceding example, `/business/` is an optional path that corresponds to an actual subdirectory in the protected path. These subdirectories can be any number of levels deep, and you can assign various users privileges for different subdirectories as described in "Granting Permissions".

A Web page link to a live broadcast looks like this:

    http://helixserver.example.com/ramgen/broadcast/secure/player/live.rm

Here, `/broadcast/` is the appropriate broadcast mount point, as described in Chapter 7. The encoder that sends the stream to Helix Universal Server must supply the `/secure/player` virtual path along with the broadcast stream name.

| Note: As noted in "Setting Up Commerce Rules", a commerce rule for the `/broadcast/secure/player` protected path is not predefined, so you must create it to secure broadcasts through player ID validation.

| For More Information: For background on URLs and links, see "Writing Links to Content".

| © 2002 RealNetworks, Inc. All rights reserved. For more information, visit RealNetworks Click here if the Table of Contents frame is not visible at the left side of your screen.